IBIS Macromodel Task Group

Meeting date: 28 April 2020

Members (asterisk for those attending):
Achronix Semiconductor      * Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                            * Jared James
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                            * Todd Bermensolo
                              Stephen Slater
Marvell                       Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Fangyi to send the updated DQ DQS clock forwarding draft to Randy to be
  submitted to the Open Forum as a BIRD.
  - Done.  Submitted as BIRD204 and introduced at the last Open Forum meeting.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the April 21
meeting.  Walter moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD201 - Addressing Radek's comments:
Radek noted questions he had raised at the Open Forum meeting in advance of the
scheduled vote (which was cancelled).  He said he thought the interface between
statistical and time-domain based training needed to be more precisely defined.
He said we need to carefully define how "Dual" mode models should work and what
the EDA tool is supposed to do.  He noted that the Open Forum had agreed to send
the BIRD back to ATM for discussion.  He said Walter had sent out a quick update
and clarification after the Open Forum meeting, but he thought it wasn't quite
ready yet.

Radek said he wasn't prepared to discuss it further at this meeting.  Arpad
asked if it was a technical change or just a clarification that was required?
Radek said it was technical.  Arpad asked if the intent was to change behavior?
Radek said the intent wasn't really clearly spelled out in the current BIRD.
Walter noted that he had a clear intent for how Dual mode models should work.
He asked Radek to send him suggested changes.  Radek took an AR to email Walter
proposed changes.

Bob noted several editorial issues: "support" -> "supports" and use of undefined
"Init" in the BCI_training_mode row in the usage table.  Walter said "Init"
should be replaced with "Impulse".  Radek and Walter asked that we defer further
discussion and gather feedback and changes via email.

Gap in IBIS for sampling with statistical mode AMI Models:
Hansel shared a new presentation about a new BIRD draft.

slide 3:
- Statistical mode is used a lot.
- Currently no means for the Rx AMI model to share precursor, cursor,
  postcursor locations with the EDA tool.
- Larger question: Who controls calculation and presentation of the eye?
- Shouldn't we give model makers as much control as possible?
  
Arpad suggested that we have a similar issue with the GetWave() flow because
returning clock ticks is optional.  He said that if a model does not return
clock ticks, then the EDA tool is left to formulate the eye.  Hansel agreed.
Arpad said one easy solution in the GetWave() flow might be to make returning
clock ticks required.

slide 4: Problem statement
- AMI_Init() in IBIS 7.0 provides no way for the model to share the sampling
  point location with the tool.
- We need a way to specify the cursor location, and we can then assume a 1 UI
  offset to the pre and post cursors.
  
slide 5: Proposal
- Introduce a new Reserved parameter Rx_Decision_Time
  - Usage Out, Type Float
  - Model outputs a time value in seconds that is the receiver decision point.
  - The time is with respect to time zero of the IR returned by the model.
  - Call it the "mean" or "median" sampling point.
  - If omitted, the EDA tool must determine the receiver decision point itself.

Hansel noted that the model maker only has the IR to work with.  He said that
since the model maker can't return the distribution of jitter, the decision
point must be considered the "mean" or "median" sampling point.

Along the lines of his earlier comment about clock ticks in the GetWave() flow,
Arpad suggested we might want to make this a required parameter.  He also
suggested that the statement in Usage Rules:
 "If omitted, the EDA tool will have to determine the receiver decision point
  on its own."
might be venturing too far into specifying what the EDA tool should do.

slide 6: Demo
- Illustrative example
- RX AMI model with CTLE, FFE, DFE
- Model communicates via AMI_Init() call and returns Rx_Decision_Time.
  - This is essentially the cursor position relative to t=0.
  - Describes the position of the cursor, and by inference the pre and post
    cursors.

slide 7: Time domain generation of pulse and step responses from an impulse
         response.
- Illustration/explanation for model and tool developers
  - Conversion of impulse response to pulse or step responses.
  - Share some insight into the process.  Probably won't be part of the
    specification, but perhaps part of the background information for the BIRD.
- Important because IBIS doesn't define pulse and step responses.
  - Cursor positions are always defined with respect to a pulse or step
    response.
- Impulse response contains no information related to unit interval.

Michael noted that the unit interval is provided to the model in the bit_time
argument to AMI_Init().  He said that the unit interval could only be inferred
directly from a waveform input if the unfiltered pulse waveform itself were
available.

Ambrish asked if the BIRD might include a few generic steps on how to generate
the value of this new Rx_Decision_Time, as an aid to both model makers and tool
vendors.  Hansel said he was open to this idea.  Walter said the question was
whether that should be in the BIRD itself (supporting details) or in a separate
document.  Walter said he didn't object to the idea in general, but he wasn't
sure it was necessary.  Fangyi said he agreed with Walter and Arpad that we
don't necessarily want to prescribe what the EDA tool should do.  Ambrish said
he was only looking for guidelines on how the value is used.  If the EDA tool
has to know how to apply the value, then tool vendors have to know how the model
derived it.  Walter said that some standard things that a tool does, such as
generating a pulse response from an impulse response, might just be left as
expected knowledge in the industry.  Arpad said we could revisit this question
when we review the BIRD itself.

slide 8: Summary of some questions/feedback/suggestions.

slide 9: What is the symbol time/bit time used for PAM4?
- Question from Michael
- Refers to the "...bit time/symbol time..." statement in the Definition of the
  Issue section.
- Is "symbol time" actually used, so PAM4 is supported?

Walter noted that symbol time and bit time are the same thing for NRZ.  He said
it was a poor choice to name the argument bit_time, and that symbol interval
would have been better.  Walter/Fangyi/Michael/Arpad noted that IBIS 7.0 states
that symbol time is placed in the bit_time argument for PAM4.  So, the group
agreed that EDA tools will provide the proper symbol time for this BIRD and
PAM4 is supported.  Michael noted that the PAM4 symbol time being passed in
bit_time is explained on pages 203 and 208 of IBIS 7.0.  Ambrish suggested this
proposal's text should only refer to symbol time.

slide 10: Should we use a different name for the new parameter?
No one objected to the name.  Ambrish said he thought it was good.

slide 11: Should we also allow specification of the value as a fractional UI?
- Question from Michael
- Should Type UI be allowed as well as Float? (question from Michael)

Hansel wondered if a fractional UI specified relative to a time 0 would be
readily understood by model makers.  Arpad noted that Vladimir had preferred
absolute time, but that it's not hard to convert from one to the other.  Michael
said he had asked because he wondered, if something were a fixed fraction of the
UI (i.e., it changes with the UI), if this would make it easier to specify.
Radek said he saw no issue with supporting both, as they are interchangeable.
The group agreed.

slide 12: Do we call it mean or median sample point?
Walter suggest that "ideal" might be a better term, since we are talking about
the point where we want to make a decision, but the actual decision time will
move with impairments like Dj, Rj, etc.  Fangyi agreed that from a tool's
perspective the model returns a sampling time and all the jitter is relative to
that.  Radek said he thought mean and median were confusing, and he suggested
using Walter's proposed "ideal".  Walter said "ideal" implies that you'll be
adding jitter to it.  Arpad noted the importance of the language "returned by
the model" in:
 "... with respect to time zero of the impulse response returned by the model."
He said he often sees cases where the IR returned by AMI_Init() is shifted
relative to the input IR, and this language makes it crystal clear where the
Rx_Decision_Time is applied.  Hansel credited Ambrish with suggesting this
language.

slide 13: Clarifying the description of Rx_Decision_Time
Hansel again noted Ambrish's "returned by the model" language and said this
leaves the ball in the model developer's court.  If the model maker does
anything to introduce extra delay, for example, this has to be reflected in the
output value of Rx_Decision_Time.  Michael said his suggestion had been to
adjust the text for clarity.  He said the definition refers to "decision point",
which in previous usages in IBIS has always referred to a physical location.
However, here we are talking about a point in time.  So, does it refer to delay
from t=0 to the logic transition?  We have to specify what the delay is between.
Arpad said this could open a can of worms because the Rx could have a
+-sensitivity range and then you'd be into questions of the edge rate and
hysteresis.

Walter suggested Hansel add Ambrish's question about whether to provide guidance
on generation of pulse and step responses as an additional slide for next time.
He also suggested Arpad's question about requiring clock ticks or making
Rx_Decision_Time mandatory be added as a slide for next time.

- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Radek to send suggested BIRD201 clarification language to Walter.

-------------
Next meeting: 05 May 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
